1. Field of the Invention
The present invention relates to a method, system and program for configuring a source device to communicate with at least one target device.
2. Description of the Related Art
A virtual tape storage system consists of data management software and a pool of hard disk drives that caches data to or from tape drives and tape cartridges. Host systems perform input/output (I/O) operations with respect to the tape drives by performing I/O operations with respect to the virtual tape server that emulates the tape storage. In the prior art, one or more virtual tape servers (VTS), such as the International Business Machines (IBM) Magstar** Virtual Tape Server, are each integrated with a tape library comprising numerous tape cartridges and tape drives and a direct access storage device (DASD) comprised of numerous interconnected hard disk drives. The DASD functions as a cache to volumes in the tape library. In VTS operations, the virtual tape server intercepts a host request to access a volume in the tape library and returns data for such requests from the DASD. If the volume is not in the DASD, then the virtual tape server recalls the volume from the tape drive to the DASD. The virtual tape server can respond to host requests for volumes in tape cartridges from DASD substantially faster than responding to requests for data from a tape drive. In this way, the DASD functions as a tape volume cache for volumes in the tape cartridge library. AIX, ESCON, MAGSTAR, and RS/6000, OS/390, Tivoli are registered trademarks of IBM.
Two virtual tape servers can be combined to create a peer-to-peer virtual tape server system. In a peer-to-peer virtual tape server, two virtual tape servers, each integrated with a separate tape library and DASD, can provide access and storage for the same data volumes (i.e., peer-to-peer environment). In such peer-to-peer VTS systems, if an operation to recall a file from one virtual tape server subsystem and tape library fails, then the file may still be recalled from the other virtual tape server subsystem and tape library. This redundant architecture provides greater data and tape availability and improved data shadowing in the event a tape or VTS in one subsystem is damaged.
In the VTS peer-to-peer system, virtual tape controllers receive host I/O requests and direct such requests to one of the VTS subsystems (an example of a virtual tape controller is the IBM AX0 Virtual Tape Controller (“VTC”) which acts as an intelligent switch between the two virtual tape servers). The VTC copies the logical volume from the virtual tape server that received the write to the other virtual tape server. Many peer-to-peer configurations include more than one virtual tape controller to provide redundancy and no single point of failure. When one of the virtual tape controllers is off-line, all host activity is directed to the remaining one or more virtual tape controllers. All virtual tape controllers in a Peer-to-Peer VTS, as a group, elect one of the VTSs to be the focal point or master VTS of the Peer-to-Peer VTS and control the switchover to the other VTS if the master VTS fails. The virtual tape controllers provide a logical view of the peer-to-peer virtual tape system to the host. The virtual tape controllers are also referred in the art as intermediate controllers or directors.
Current Peer-to-Peer VTS systems utilize four VTCs to manage the flow of data between two VTSs. In prior art implementations, each VTS may be addressed through 64 different device addresses, also referred to as customer device addresses, where each of the four VTCs handle 16 of the customer devices addresses to the VTS. Additionally, there are typically three copy device addresses per VTC which provide addresses used for copying updates between the VTSs and four broadcast device addresses used by all the four VTCs to communicate with each other. The VTS must support 80 device addresses for the tape, copy, and broadcast devices. The term “device address” as used herein in connection with customer devices, copy devices and broadcast devices refers to a path to one of these or another components.
As the Peer-to-Peer systems expand and add additional VTCs and VTSs capable of supporting additional customer device addresses beyond 64, the task of configuring the addresses used by the VTCs increases in complexity. Configuration is further complicated if the VTSs in a Peer-to-Peer system have different addressing capabilities, e.g., one supports 64 device addresses and another supports 128 device addresses, and/or the VTCs have different addressing capabilities, e.g., one supports 16 device addresses and another supports 32 device addresses.
For these reasons, there is a need in the art to provide improved techniques for handling configuration of systems in environments where multiple sets of device addresses, such as VTCs, communicate with another set of device addresses, such as VTSs.